Service-oriented architectures may decompose systems into coarse-grained software artifacts (namely services) that expose information, rules and processes across ownership domains. This approach may lead to architectures that are aligned with the business domain and can seamlessly evolve in response to changes in business requirements. On the other hand, since services are coarse-grained, their reuse and evolution may require the introduction of complex adapters. Indeed, when services encapsulate long-running business processes, their interfaces may often be conversational, meaning that they capture multiple interactions related through control-dependencies. Thus, when reusing a service, one needs to deal with mismatches, not only at the level of individual interactions, but also across interactions occurring in the context of a conversation.
For example, consider the situation where a customer service is required to interact with a supplier service. The customer service may send a purchase order (PO) and then expect to receive a single order response. The supplier service on the other hand may receive the PO and reply with a PO response followed by one or more PO updates (to keep the customer informed of the fulfillment of the order), until the supplier service finally issues a PO confirmation to mark the completion of the fulfillment process. In this example, the services are incompatible because the customer service never receives the expected single order response from the supplier service, but instead the customer service may receive multiple PO responses and a PO confirmation that the customer service may not be able to process. Thus, the interfaces or service descriptions that may represent the life cycle of each of the services have at least one mismatch. In this example, the interface of the customer service may be based on a fragment of the extensible markup language (XML) common business library (xCBL), which is an XML component library or business-to-business e-commerce framework, or it may be based on a fragment of the universal business language (UBL), which is a generic XML interchange format and set of rules for exchanging electronic business documents. Whereas, the supplier service interface may be based on a RosettaNet standard interface process, which is another interchange format and set of rules for exchanging electronic business documents.
One approach to reconcile incompatibilities such as those exposed by this example may be to introduce adapters that resolve differences between pairs of services on a case-by-case basis. However, this approach may lack scalability and lead to a proliferation of adapters that need to be maintained as the underlying services and their interconnections evolve. Consequently, there may be a need for improved techniques to reconcile incompatible services.